Microdevices, such as integrated microcircuits and microelectromechanical systems (MEMS), are used in a variety of products, from automobiles to microwaves to personal computers. Designing and fabricating microdevices typically involves many steps, known as a “design flow.” The particular steps of a design flow often are dependent upon the type of microcircuit, its complexity, the design team, and the microdevice fabricator or foundry that will manufacture the microcircuit. Typically, software and hardware “tools” verify the design at various stages of the design flow by running software simulators and/or hardware emulators, and errors in the design are corrected or the design is otherwise improved.
Several steps are common to most design flows for integrated microcircuits. Initially, the specification for a new circuit is transformed into a logical design, sometimes referred to as a register transfer level (RTL) description of the circuit. With this logical design, the circuit can be described in terms of both the exchange of signals between hardware registers and the logical operations that can be performed on those signals. The logical design typically employs a Hardware Design Language (HDL), such as the Very high speed integrated circuit Hardware Design Language (VHDL). As part of the creation of a logical design, a designer will also implement a place-and-route process to determine the placement of the various portions of the circuit, along with an initial routing of interconnections between those portions. The logic of the circuit is then analyzed, to confirm that it will accurately perform the functions desired for the circuit. This analysis is sometimes referred to as “functional verification.”
Various electronic design automation tools can perform verification checks on the logical design. For example, a clock-domain tool can analyze the logical design to determine whether interaction between different clock domains in the logical design can cause glitches, e.g., due to signal meta-stability, which may lead to system failure. The clock-domain tool typically converts or synthesizes the logical design into a device design, for example, in the form of a word-level netlist, and performs one or more static checks on the word-level netlist. Some of the static checks can traverse the word-level netlist to identify locations of clock domain crossing points and determine whether the logical design includes adequate protection circuitry, such as synchronizers, at the identified locations to synchronize signal exchanges between the clock domains. The clock-domain tool can further augment the static checks with other verification processes, such as formal verification, simulation, emulation, or the like, for example, to verify operability of transfer protocols between clock domains, to identify delays through protection circuitry due to meta-stability, or the like.
While the clock-domain tool can effectively verify clock domain crossings of logical designs, the duration of and the resources consumed during the static check can vary based on the specific coding of the logical designs provided to the clock-domain tool. For example, when a logical design includes cyclical assignment of instances, the clock-domain tool typically synthesizes or converts those cyclical assignments into combinational loops in a corresponding word-level netlist. Since traversal of the combinational loops by the clock-domain tool is onerous, often requiring intensive non-linear computation to traverse correctly, the more combinational loops that are present in the word-level netlist, the longer and more resource intensive netlist traversal becomes. This problem can be exacerbated when the clock-domain tool implements a hierarchical verification scheme for clock domain crossings, for example, sub-dividing the word-level netlist into various levels of abstraction, such as block-level verification, top-level verification, localized verification, or the like, each of which performs a separate netlist traversal.